<p>This chapter is a collection of frequently asked questions (FAQ) and
corresponding answers following the popular USENET tradition. Most of these
questions occurred on the Newsgroup <code><a href="news:comp.infosystems.www.servers.unix">comp.infosystems.www.servers.unix</a></code> or the mod_ssl Support
Mailing List <code><a href="mailto:modssl-users@modssl.org">modssl-users@modssl.org</a></code>. They are collected at this place
to avoid answering the same questions over and over.</p>
<p>Please read this chapter at least once when installing mod_ssl or at least
search for your problem here before submitting a problem report to the
author.</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#about">About The Module</a></li>
<h2><a name="about" id="about">About The Module</a></h2>
<ul>
<li><a href="#history">What is the history of mod_ssl?</a></li>
<li><a href="#y2k">mod_ssl and Year 2000?</a></li>
<li><a href="#wassenaar">mod_ssl and Wassenaar Arrangement?</a></li>
</ul>
<h3><a name="history" id="history">What is the history of mod_ssl?</a></h3>
<p>The mod_ssl v1 package was initially created in April 1998 by <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> via porting <a href="mailto:ben@algroup.co.uk">Ben Laurie</a>'s <a href="http://www.apache-ssl.org/">Apache-SSL</a> 1.17 source patches for
Apache 1.2.6 to Apache 1.3b6. Because of conflicts with Ben
Laurie's development cycle it then was re-assembled from scratch for
Apache 1.3.0 by merging the old mod_ssl 1.x with the newer Apache-SSL
1.18. From this point on mod_ssl lived its own life as mod_ssl v2. The
first publicly released version was mod_ssl 2.0.0 from August 10th,
1998. </p>
<p>After US export restrictions on cryptographic software were
loosened, <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> became part of the Apache HTTP
Server with the release of Apache httpd 2.</p>
<h3><a name="wassenaar" id="wassenaar">Is mod_ssl affected by the Wassenaar Arrangement?</a></h3>
<p>First, let us explain what <dfn>Wassenaar</dfn> and its <dfn>Arrangement on
Export Controls for Conventional Arms and Dual-Use Goods and
Technologies</dfn> is: This is a international regime, established in 1995, to
control trade in conventional arms and dual-use goods and technology. It
replaced the previous <dfn>CoCom</dfn> regime. Further details on
both the Arrangement and its signatories are available at <a href="http://www.wassenaar.org/">http://www.wassenaar.org/</a>.</p>
<p>In short, the aim of the Wassenaar Arrangement is to prevent the build up
of military capabilities that threaten regional and international security
and stability. The Wassenaar Arrangement controls the export of
cryptography as a dual-use good, that is, something that has both military and
civilian applications. However, the Wassenaar Arrangement also provides an
exemption from export controls for mass-market software and free software.</p>
<p>In the current Wassenaar <cite>List of Dual Use Goods and Technologies And
Munitions</cite>, under <q>GENERAL SOFTWARE NOTE (GSN)</q> it says
<q>The Lists do not control "software" which is either: 1. [...] 2. "in
the public domain".</q> And under <q>DEFINITIONS OF TERMS USED IN
THESE LISTS</q> we find <q>In the public
domain</q> defined as <q>"technology" or "software" which has been made
available without restrictions upon its further dissemination. Note:
Copyright restrictions do not remove "technology" or "software" from being
"in the public domain".</q></p>
<p>So, both mod_ssl and OpenSSL are <q>in the public domain</q> for the purposes
of the Wassenaar Arrangement and its <q>List of Dual Use Goods and
Technologies And Munitions List</q>, and thus not affected by its provisions.</p>
This is the last way of submitting your problem report. You should only
do this if you've already posted to the mailing lists, and had no success.
Please follow the instructions on the above page <em>carefully</em>.
</li>
</ol>
<h3><a name="reportdetails" id="reportdetails">What information should I
provide when writing a bug report?</a></h3>
<p>You should always provide at least the following information:</p>
<dl>
<dt>Apache and OpenSSL version information</dt>
<dd>The Apache version can be determined
by running <code>httpd -v</code>. The OpenSSL version can be
determined by running <code>openssl version</code>. Alternatively, if
you have Lynx installed, you can run the command <code>lynx -mime_header
http://localhost/ | grep Server</code> to gather this information in a
single step.
</dd>
<dt>The details on how you built and installed Apache+mod_ssl+OpenSSL</dt>
<dd>For this you can provide a logfile of your terminal session which shows
the configuration and install steps. If this is not possible, you
should at least provide the <code class="program"><a href="../programs/configure.html">configure</a></code> command line you used.
</dd>
<dt>In case of core dumps please include a Backtrace</dt>
<dd>If your Apache+mod_ssl+OpenSSL dumps its core, please attach
a stack-frame ``backtrace'' (see <a href="#backtrace">below</a>
for information on how to get this). Without this information, the
reason for your core dump cannot be found
</dd>
<dt>A detailed description of your problem</dt>
<dd>Don't laugh, we really mean it! Many problem reports don't
include a description of what the actual problem is. Without this,
it's very difficult for anyone to help you. So, it's in your own
interest (you want the problem be solved, don't you?) to include as
much detail as possible, please. Of course, you should still include
all the essentials above too.
</dd>
</dl>
<h3><a name="coredumphelp" id="coredumphelp">I had a core dump, can you help me?</a></h3>
<p>In general no, at least not unless you provide more details about the code
location where Apache dumped core. What is usually always required in
order to help you is a backtrace (see next question). Without this
information it is mostly impossible to find the problem and help you in
fixing it.</p>
<h3><a name="backtrace" id="backtrace">How do I get a backtrace, to help find
the reason for my core dump?</a></h3>
<p>Following are the steps you will need to complete, to get a backtrace:</p>
<ol>
<li>Make sure you have debugging symbols available, at least
in Apache. On platforms where you use GCC/GDB, you will have to build
Apache+mod_ssl with ``<code>OPTIM="-g -ggdb3"</code>'' to get this. On
other platforms at least ``<code>OPTIM="-g"</code>'' is needed.
</li>
<li>Start the server and try to reproduce the core-dump. For this you may
want to use a directive like ``<code>CoreDumpDirectory /tmp</code>'' to
make sure that the core-dump file can be written. This should result
in a <code>/tmp/core</code> or <code>/tmp/httpd.core</code> file. If you
don't get one of these, try running your server under a non-root UID.
Many modern kernels do not allow a process to dump core after it has
done a <code>setuid()</code> (unless it does an <code>exec()</code>) for
security reasons (there can be privileged information left over in
memory). If necessary, you can run <code>/path/to/httpd -X</code>
manually to force Apache to not fork.
</li>
<li>Analyze the core-dump. For this, run <code>gdb /path/to/httpd
/tmp/httpd.core</code> or a similar command. In GDB, all you
have to do then is to enter <code>bt</code>, and voila, you get the
backtrace. For other debuggers consult your local debugger manual.
</li>
</ol>
</div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/ssl/ssl_faq.html" title="English"> en </a></p>
</div><div id="footer">
<p class="apache">Copyright 1995-2006 The Apache Software Foundation or its licensors, as applicable.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
